Archive: 30 posts

---

LBP is not finished. It shouldn't have been released back in Spetember. Maybe now... LBP needs a lot of work ( a little to much...) because of the glitches, bugs, ect.

2009-03-29 21:25:00 Author: blizzard_cool Posts: 752

---

LBP is not finished. It shouldn't have been released back in Spetember. Maybe now... LBP needs a lot of work ( a little to much...) because of the glitches, bugs, ect. Yeah, I know what you mean. I know someone who got LBP, played on the first level and took it back, someone who's taking it back who made 4 levels and got bored (although they might wait for the gllobal lighting tool I'e told them about) and someone who hasn't bothered completing it yet (they also have a tonne of other games they've never played aswell.

2009-03-29 21:41:00 Author: S-A-S--G-U-N-R Posts: 1606

---

Care to elaborate? The only flaws I can think of that would cause a considerable amount of annoyance is the sometimes laggy online and the corrupted data. Hardly something to delay a game for 6 months.

2009-03-29 21:43:00 Author: Killian Posts: 2575

---

Well, as Phil Harrison said when LBP was demonstrated, "the release of the Blu-Ray disc isn't the final day. It's day 1 of the project". but yeah, everything shown at GDC 07 was the entire game so far apparently, so it's amazing they made ALL THAT in that short a time O_o. I guess sony was rushing them, really.

2009-03-29 22:12:00 Author: RockSauron Posts: 10882

---

I don't know how other people feel about this but I still love the game - bugs and all. What I'm really amazed about is how hard MM seems to be working to get it fixed and improved even. They are paying attention to the players/creators too. To get that kind of commitment and respect for it's players from a software developer I'm more than happy to play it while they work out the kinks.

2009-03-29 22:33:00 Author: Morgana25 Posts: 5983

---

Keep in mind - there are far fewer bugs in LBP than many think. A lot of "perceived" bugs are actually just products of a complex designer. I've developed a number of complex levels and have not run into anything I consider a bug in a long time. As a software developer, I've found LBP to be relatively clean. Here's my take on a few of the bugs: Corruption - I've run into much worse corruption issues in other environments. Backing up is a way of life for me. I'm not saying it's right - but when you're dealing with something as complex as a "game creator" there are bound to be issues like this. Ungluing "bug" - the objects in LBP are stored in structures. When you glue things together, one object becomes part of a different structure. It's not something you visibly see. What many consider to be an ungluing bug is generally just not understanding what is glued to what, and in what order. Entire areas shaking themselves apart - generally this is due to pressure from material pushing things around based on the physics engine. This behavior is also what makes LBP good - having physics to create a more organic environment. So, most likely if you have this issue it's because you've designed something in a way that breaks - make sure your larger objects are glued properly to prevent this. Are there some issues? Sure... but I'm actually AMAZED that an environment this complex is as clean as it is.

2009-03-29 23:59:00 Author: CCubbage Posts: 4430

---

Keep in mind - there are far fewer bugs in LBP than many think. A lot of "perceived" bugs are actually just products of a complex designer. I've developed a number of complex levels and have not run into anything I consider a bug in a long time. As a software developer, I've found LBP to be relatively clean. Here's my take on a few of the bugs: Corruption - I've run into much worse corruption issues in other environments. Backing up is a way of life for me. I'm not saying it's right - but when you're dealing with something as complex as a "game creator" there are bound to be issues like this. Ungluing "bug" - the objects in LBP are stored in structures. When you glue things together, one object becomes part of a different structure. It's not something you visibly see. What many consider to be an ungluing bug is generally just not understanding what is glued to what, and in what order. Entire areas shaking themselves apart - generally this is due to pressure from material pushing things around based on the physics engine. This behavior is also what makes LBP good - having physics to create a more organic environment. So, most likely if you have this issue it's because you've designed something in a way that breaks - make sure your larger objects are glued properly to prevent this. Are there some issues? Sure... but I'm actually AMAZED that an environment this complex is as clean as it is. Cubbage has a point. I've been using UnrealEd and Hammer for the past few months, and you'd be amazed at the constant workarounds you have to come up with in order to get something to work the way it should. Lighting in Hammer is horrible; it's so bad that they actually have ways for you to set lighting positions manually per object so the lighting is consistent. LittleBigPlanet is a mass-marketed level creator, and it should be as bug-free as possible, but when compared to most other level creators, it's very clean of buggy behavior.

2009-03-30 00:53:00 Author: ConfusedCartman Posts: 3729

---

I have seen a lot of games and a lot of level editors and believe me considering the content of the game and the complexity of the leveleditor and at the same time the accessibilty of the the editor, LBP is top notch software. You will never have a bug free piece of software of this magnitude these days.

2009-03-30 07:33:00 Author: Fjonan Posts: 359

---

It really is an amazing piece of software. Having started this project in beta, all I can say is it has come A LONG way. Really.

2009-03-30 08:40:00 Author: Jaeyden Posts: 564

---

Yeah, I know what you mean. I know someone who got LBP, played on the first level and took it back, someone who's taking it back who made 4 levels and got bored (although they might wait for the gllobal lighting tool I'e told them about) and someone who hasn't bothered completing it yet (they also have a tonne of other games they've never played aswell. The bright side is that they probably would have been H4Hers or other noob things.

2009-03-30 12:29:00 Author: Sackdragon Posts: 427

---

Blizzard cool is right though, The only thing worse was the fallout 3 addon "The Pitt" and that problem was solved after 2 days. (MM could learn a thing or 2 from that) @ killian, the corrupted date is THE reason to delay a game and make sure nobody loses his work, period! It started in December, and even now the bugs still continue to haunt me. that is just retarded. (and retardedly slow) @ morgana, thats complete bogus, they shouldve fixed it by now. 3 months is WAY!!! to long to fix a bug. @ccubbage, cmon man, the corruption it one of the dumbest "bugs" ive seen in my live as an enviroment artist/quality assurance guy. And the area's shaking apart bug can often easily be solved by understanding the engine, problem is though.. Ive had it a couple of times that my darkmattermaterials gave up, and started rotating/moving around. And thats just f-ed up, and again retarded. @ cartman, ive been working with the ued 2.0, 2.5 and 3.0 for a total of almost 10 years, and besides ued 1.0 its one of the most stable editors around, way more stable than lbp-editor has been up untill now. And since UED has autoback, you dont have to create backups every 5 or so minutes, it does it for you. Its also more user-friendly when you know the basics, and things wont go b0rk all of a sudden, and if it does (bsp holes etc) its often the fault of the one working on the map, unlike lbp where atm most faults are from MM's unexperienced coders. Cubbage has a point. I've been using UnrealEd and Hammer for the past few months, and you'd be amazed at the constant workarounds you have to come up with in order to get something to work the way it should. so not true, learn the basics before you state something like this. @fjonan, the lbp editor isnt that complex, it is just build in a way that let you create complex stuff, but no mather how complex it is, it just uses the basic switches/triggers etc.

2009-03-30 13:14:00 Author: Luos_83 Posts: 2136

---

Hello? You are missing out on vector based objects, material properties which ultimately work with ... and that is what I mean with complex ... a physicsengine that has strength, friction, weight and polygon based collission detection. All of which does not exist in UEd last I checked. And you could not sit a 10 year old before the UEd and another one before the LBP Ed and have a nice easy level in the same time all learning by himself. Trying to compare UEd and LBP Ed in detail does make no sense at all since they do have completely differnt target audience and genres. It is a hell of a lot different to make a shooter or shooterbased level in a 3D environment than a platformer. I got bsp errors sometime without messing up my work and UEd was not very nice and forgiving in that part. You could not just drop in, play around a little and have a nice thing in the end. It was a lot of reading to even get startet with this thing. Criticizing coders you don't know with schedules you don't know working on an engine you don't know as unexperienced is childish. If you are a quality assurance guy you should know, that "fixing a bug" is not as simple as it seems. What might look easy and obvious from the outside is absolutely not from the inside. A rule says, there is a bug for every 200 lines of code. So if you need another 200 to fix a bug you can start calculating.

2009-03-30 13:49:00 Author: Fjonan Posts: 359

---

@ccubbage, cmon man, the corruption it one of the dumbest "bugs" ive seen in my live as an enviroment artist/quality assurance guy. And the area's shaking apart bug can often easily be solved by understanding the engine, problem is though.. Ive had it a couple of times that my darkmattermaterials gave up, and started rotating/moving around. And thats just f-ed up, and again retarded. I understand you have some qualifications, however you have to remember there are other members on this site who are also fairly qualified. We're not all young teenage gamers (although there is nothing wrong with that). I'm the head developer at 2 software companies, I've been a technical consultant for Microsoft on their Accounting software, I've been an instructor at TechEd, QuickBooks and Peachtree use me for SDK testing every year, and I used to be a professional video game designer back in the mid to late 80's. As Fjonan said, there is a VAST difference between the Unreal editor and the LBP create mode. The amount of physics going on, married with the fact that the physics are all happening in real time in create mode. I think the corruption is a horrible issue, however I can completely understand how it could happen. Putting this kind of open-ended power in the hands of gamers is a huge risk. There is NO WAY in testing you could account for all the possibilities. Shoot - QuickBooks had a version a while back that corrupted data and they have one of the best testing teams around AND their backend isn't nearly as complex as this.

2009-03-30 14:25:00 Author: CCubbage Posts: 4430

---

At least three things don't set the dirty bit and are not recognized as a separate undo step: editing a sticker or deco, changing global lighting/fog etc, and most annoyingly - because of the already clunky interface - reassigning/moving an emitted object. And that has been the case since November. If you connect a switch to something made of dissolve and the switch fires immediately on unpause, the dissolve dissolves but you cannot undo it - you have to go back to before you connected the switch. This too has been the case since November. If an emitter is connected to a switch that is currently "on", it will fire when you undo unpausing. The emitted object will even move in pause mode, no less. Also has been the case since November. These issues haven't been fixed over the course of five months, or ten minor revisions (including those purported to contain data only). It seems that nobody at MM actually uses the create tool in anger, and once again, that proves rather detrimental to quality.

2009-03-30 14:39:00 Author: tameturtle Posts: 150

---

At least three things don't set the dirty bit and are not recognized as a separate undo step: editing a sticker or deco, changing global lighting/fog etc, and most annoyingly - because of the already clunky interface - reassigning/moving an emitted object. And that has been the case since November. If you connect a switch to something made of dissolve and the switch fires immediately on unpause, the dissolve dissolves but you cannot undo it - you have to go back to before you connected the switch. This too has been the case since November. If an emitter is connected to a switch that is currently "on", it will fire when you undo unpausing. The emitted object will even move in pause mode, no less. Also has been the case since November. These issues haven't been fixed over the course of five months, or ten minor revisions (including those purported to contain data only). It seems that nobody at MM actually uses the create tool in anger, and once again, that proves rather detrimental to quality. I totally agree with these (although some of them are minor quibbles and I wouldn't consider "bugs"). The only one of these that ever "got me" was the dirty bit not being set on changing environment or the stickers. Most likely they are taking their time with the current update because they want to carefully look at things and not be rushed.

2009-03-30 14:58:00 Author: CCubbage Posts: 4430

---

At least three things don't set the dirty bit and are not recognized as a separate undo step: editing a sticker or deco, changing global lighting/fog etc, and most annoyingly - because of the already clunky interface - reassigning/moving an emitted object. And that has been the case since November. If you connect a switch to something made of dissolve and the switch fires immediately on unpause, the dissolve dissolves but you cannot undo it - you have to go back to before you connected the switch. This too has been the case since November. If an emitter is connected to a switch that is currently "on", it will fire when you undo unpausing. The emitted object will even move in pause mode, no less. Also has been the case since November. These issues haven't been fixed over the course of five months, or ten minor revisions (including those purported to contain data only). It seems that nobody at MM actually uses the create tool in anger, and once again, that proves rather detrimental to quality. And there's also the bug where if you copy certain objects with properties already set (like music boxes) too fast or too many times, their properties become linked so that if you change one, the other changes too (worse yet, if you change the duplicated one, it doesn't save your changes). But all these annoyances aside, I've never seen such a smooth, versatile and easy-to-use creation tool. It's not perfect, but it's light years beyond anything else used for creation of this magnitude in both consistency and user-friendliness.

2009-03-30 15:57:00 Author: sny Posts: 144

---

I'm the head developer at 2 software companies, I've been a technical consultant for Microsoft on their Accounting software, I've been an instructor at TechEd, QuickBooks and Peachtree use me for SDK testing every year, and I used to be a professional video game designer back in the mid to late 80's. Can you hook my up with an internship this summer? I'm 1 year from having my undergraduate degree in CompSci. Back on topic, the corruption bug is the only one that really worries me. Sure there are some minor bugs in create mode, but they really are minor.

2009-03-30 16:21:00 Author: Walter-Kovacs Posts: 542

---

And you could not sit a 10 year old before the UEd and another one before the LBP Ed and have a nice easy level in the same time all learning by himself.no? one of my friends (neoduck) learned everything himself while he was young, and he now is one of the better Env. artists I know. Also my good friend Will learned his 2 kids at age 8 and 9 how the ued works. Yes it takes more time, but the reward is much better. Trying to compare UEd and LBP Ed in detail does make no sense at all since they do have completely differnt target audience and genres. It is a hell of a lot different to make a shooter or shooterbased level in a 3D environment than a platformer.You could make lbp with the ued and some coding. ued doesnt instantly mean fps/shooter, since you can also create EVERY other type of game with this engine and editor. U are mistaking unreal tournament with the unreal engine and its editor. ( http://en.wikipedia.org/wiki/List_of_Unreal_Engine_games ) for almost all unreal engine games. I got bsp errors sometime without messing up my work and UEd was not very nice and forgiving in that part. You could not just drop in, play around a little and have a nice thing in the end. It was a lot of reading to even get startet with this thing.If you have an bsp error, you messed up. period. Unless you had the black builder brush bug, but that happened only to a few people in the ued 2.0 age. And, if you know what can cause bsp errors, you can easily solve them, either with semi solids, changing zone's or even the simple understanding of polygons in bsp will help you not to get bsp holes. A rule says, there is a bug for every 200 lines of code. So if you need another 200 to fix a bug you can start calculating.Imho, that depends on the coder and the coders he had to work with, Since clean code does exist. If a coder doesnt know where the problem is in his own code, he should start over instead of adding 200 lines of code to fix something with a workaround. Using lbp in debugmodus recreating the problem should indicate where in the code the problem is, and no mather what schedule he is on, MM should have fixed this within a month, regardless of anything else. Adding more and more updates, and not solving this one can in the end result in more problems, and like and old dutch saying: "You shouldnt build your house on quicksand" Because it doesnt mather how solid that house is, when the fundation is rotten. And thats exactly what MM is doing by not fixing this. Probably the reason for bugs is that most coders use "Templates" and change them to their liking so it works for the project they are working on, instead of creating a clean template for this specific target. At least, that is what the main coder from a decent dutch game-developer-company told me. and I used to be a professional video game designer back in the mid to late 80's.Ahh the good old 80's games, poorly designed, poorly created and often poorly thought trough, but still holds a few of the best classic games ever. (not making a point with this one, i just all of a sudden feel nostalgic) I think the corruption is a horrible issue, however I can completely understand how it could happen. Putting this kind of open-ended power in the hands of gamers is a huge risk. There is NO WAY in testing you could account for all the possibilities. Shoot - QuickBooks had a version a while back that corrupted data and they have one of the best testing teams around AND their backend isn't nearly as complex as this.they shouldve allready tried maxing out their user account before ever releasing the game/updates for the game, since this is the main thing that causes the corruption bug.

2009-03-30 16:48:00 Author: Luos_83 Posts: 2136

---

In my humble opinion and experience in QA, this game sadly was release in what I'd still call "beta state". There might be bugs in create mode but the profile and save file related problem weren't excusable, no matter you can spin it. The game came a long way but it still think their QA is lacking OR they aren't having the right priority or organisation in debug time. Bugs like dropping a huge captured paintball and making your PS3 freeze (I kid you not) is what I call a freaking basic bug and I would have found that in my first afternoon testing the creation mode. Maybe in the first hour. .

2009-03-30 17:52:00 Author: RangerZero Posts: 3901

---

Ahh the good old 80's games, poorly designed, poorly created and often poorly thought trough, but still holds a few of the best classic games ever. Ummm.... I don't know what to say to this... we used to engineer every single op code in assembly language to fit our programs into the really small amounts of available RAM (usually a max of 16k). There was no libraries and objects to just "fit" into our software. We did every single thing ourselves, and it took far better engineering skills than much of todays software where we can count on 3D engines and logic libraries. To say they were poorly designed, created, and thought through is like saying the egyptians were stupid for not using front-loader tractors to place the pyramid blocks. they shouldve allready tried maxing out their user account before ever releasing the game/updates for the game, since this is the main thing that causes the corruption bug. I thought the primary reason for corruption was a small memory overwrite issue with placing an object that contained an emitter inside another emitter. In fact, I would bet a number of corruption issues is due to this kind of thing, which is incredibly difficult to track. There might be bugs in create mode but the profile and save file related problem weren't excusable, no matter you can spin it. The game came a long way but it still think their QA is lacking OR they aren't having the right priority or organisation in debug time. Bugs like dropping a huge captured paintball and making your PS3 freeze (I kid you not) is what I call a freaking basic bug and I would have found that in my first afternoon testing the creation mode. Maybe in the first hour. I'm going to agree with this. I'm not saying they didn't make mistakes. Especially with the MGS release - I think they had PLENTY of creators that would have done a month or so testing for them in a heartbeat. They tried to reach an unrealistic deadline and broke things. I run into issues all the time that I have to report in my job every day. Things that seem like absolute basic things. Why didn't they get caught during testing? Nobody thought of doing it.... I honestly don't know whether the profile save is or isn't excusable because I don't know any details behind it. If they were dealing with data-type issues that were heavily embedded in the software, it could have been a major engineering issue to fix something they didn't originally realise was a problem. However, that being said - I simply haven't had practically any problems with this designer other than nagging little issues. Maybe being a programmer gives me a little different view of it... I may be so used to dealing with pain in the neck issues that these issues all seem really minor to me (a perception thing).

2009-03-30 19:30:00 Author: CCubbage Posts: 4430

---

The bright side is that they probably would have been H4Hers or other noob things. Yep, you're right. I think they thought they were above LBP or something, like as if it was bad because of it's simple and creative appearance. If you can't appreciate the creativity in LBP, then you're never going to be playing the full game.

2009-03-30 20:24:00 Author: S-A-S--G-U-N-R Posts: 1606

---

I'm going to agree with this. I'm not saying they didn't make mistakes. Especially with the MGS release - I think they had PLENTY of creators that would have done a month or so testing for them in a heartbeat. They tried to reach an unrealistic deadline and broke things. I run into issues all the time that I have to report in my job every day. Things that seem like absolute basic things. Why didn't they get caught during testing? Nobody thought of doing it.... I honestly don't know whether the profile save is or isn't excusable because I don't know any details behind it. If they were dealing with data-type issues that were heavily embedded in the software, it could have been a major engineering issue to fix something they didn't originally realise was a problem. However, that being said - I simply haven't had practically any problems with this designer other than nagging little issues. Maybe being a programmer gives me a little different view of it... I may be so used to dealing with pain in the neck issues that these issues all seem really minor to me (a perception thing). You're lucky you never lost your game. MANY people did. The profiles were getting really unstable when they were reaching a certain size. It's ALOT better now. Actually the profile issue probably was something really huge to fix and they probably decided to cross their fingers and release the game anyways. Sometimes you need to chose between losing some sales over that bug or losing christmas holidays and probably missing triple the amount of sales. I still think the game should have been delayed. Might be idealistic but that's the way I think. There simply is certain degree of quality you need to attain no matter what it takes when it comes down to user software production. Saving/Profile bugs are some of the most important one after blatant crashes and walkthrough breaks. Actually, it might also be like at my job. Problems are pretty much always found by the QA guys but it doesn't mean it's getting fixed. I'd even say they probably know about most the major issues already. .

2009-03-30 20:30:00 Author: RangerZero Posts: 3901

---

Actually, my profile has gotten corrupted twice.... And if I hadn't backed up, I would probably be playing something else now. I totally understand. However, I'm not totally sure the profile size its self is causing instability and corruption. The bigger the profile size the more chance there is of a memory issue in the software causing it. I have had a jammed full profile to the hilt since last november and never had any issue with corruption until I started doing more complex things in Splat Invaders Saga. (my son kept filling the whole thing up by creating a TON of little junk levels and starting new ones all the time) I think the reason this is a huge issue is because general players, who are not used to doing backups and protecting their work, are creating games - which has never really been done before in this kind of environment. I'm certainly not trying to defend lack of quality control, I just also don't want to see it blown out of proportion - for every 1 thing this game does wrong they do 10 things right, and I think it's one of the best games ever made - albiet imperfect.

2009-03-30 20:50:00 Author: CCubbage Posts: 4430

---

Actually, my profile has gotten corrupted twice.... And if I hadn't backed up, I would probably be playing something else now. I totally understand. However, I'm not totally sure the profile size its self is causing instability and corruption. The bigger the profile size the more chance there is of a memory issue in the software causing it. I have had a jammed full profile to the hilt since last november and never had any issue with corruption until I started doing more complex things in Splat Invaders Saga. (my son kept filling the whole thing up by creating a TON of little junk levels and starting new ones all the time) I think the reason this is a huge issue is because general players, who are not used to doing backups and protecting their work, are creating games - which has never really been done before in this kind of environment. I'm certainly not trying to defend lack of quality control, I just also don't want to see it blown out of proportion - for every 1 thing this game does wrong they do 10 things right, and I think it's one of the best games ever made - albiet imperfect. Well, even it's not directly a profile issue, it's "because of the profile size" anyways so from my stand point I call it a profile bug. Manner of speaking Anyways yeah, this game is doing so many things right and as I said in some other topics, the things it's doing right are some awesome that it's making me overlooking an impressive number of flaws I wouldn't forgive in another game. .

2009-03-30 20:58:00 Author: RangerZero Posts: 3901

---

@ cubbage, im sure my level was corrupted by the "full account bug" probably when I was working on my level, and when saving it, it breached the max limit and because of that, the file got corrupted. Im also starting to think my level will be lost for ever. @ the 80's games. Most games where solid, but there where so many bad games out there with glitches etc, i remember a version of an arcade robocop shooter where one kind of enemies just couldnt get hit, not even with that cobra uber gun. also remember a few games where the "monsters" appeared in such way you where stuck and had to lose health no mather what you tried. Like I said, the 80's has a few of the coolest games, and either their gameplay or originality still influence games being released at this moment. The code back then had to be more effective, since space/memory was extremely limited, while now in most games you can at least find a few mb's of actuall "useless" code, and with "useless" I mean that there probably was a better more optimal way to have written this code. But you have to agree with me, that at that time so many nonsense games reached the market may it be more popular, may it be more underground that where plain crap, and that was actually my point. but since you created a few games back then, anything we might have played when we where little brats?

2009-03-31 12:47:00 Author: Luos_83 Posts: 2136

---

The code back then had to be more effective, since space/memory was extremely limited, while now in most games you can at least find a few mb's of actuall "useless" code, and with "useless" I mean that there probably was a better more optimal way to have written this code. Sorry to not mind my business but the games back then simply were more simple to program than today's. The more complex the code/game, the more bugs you might have. And this is exactly what's happening because as the complexity increases, debut time generally does not! ($$$). A sad reality we have to cope with in the industry. Anyhow, did you send you save file to Media Molecule? You know they might be able to recover it do you? .

2009-03-31 13:49:00 Author: RangerZero Posts: 3901

---

MM is not really repairing the files you send them anymore, but they did use the info they got from the ones they did repair to, I believe, do some auto-recovery when the next build comes out. (SamProtagonist explained this on another thread somewhere recently) A note on coding the ealier arcade games vs now (mostly for info for people reading this thread). Keep in mind, even though I originally worked on games in the 80's, I'm familiar with the libraries and coding techniques in use now. It's really difficult to compare then and now. Back then generally 1 person wrote a game. And since processors were fairly slow, we had to develop extremely close to the processor. I originally developed games on the Z80 processor and ended up working with the 6502 on Atari home computers and Commodore 64's. The only language that could properly run a commercial game was straight assembly language (I used the Mac65 Macro Assembler). So the complexity of development wasn't necessarily easier.... it was just completely different. We designed routines just to put a number on the screen. We had to use vertical display interrupts (kind of like multi-tasking for each time the TV screen was refreshed) to change color palettes partially down the screen. It was absolutely RAW programming and directly hitting the CPU without any other layers. Now, the programming isn't necessarily more difficult - it's just completely different. You have the base CPU'S (which is MUCH more complex), Layers on top of that for controlling the CPU, Layers on top of that for a graphics engine, a compiler on top of that (such as C or C++), logic coders on top of that, designers on top of that...... and so on. The teams are WAY bigger, which means the load of development is spread across many more people instead of put on a single person (such as when I used to do it). (by the way, I already know RangerZero intimately knows this, so this is for everyone elses benefit) Luos_Desruc - this entire architecture obviously creates a LOT of superfluous code. There's code in an engine that may never be used in a game. It makes hunting down some issues a matter of pointing fingers because you have to hunt through whether it's IBM's, Sony's, the Engine's, OR the coders fault. However, it also creates much bigger and better games.

2009-03-31 14:14:00 Author: CCubbage Posts: 4430

---

Anyhow, did you send you save file to Media Molecule? You know they might be able to recover it do you? I wouldn't hold my breath on that. I read something over in LBPworkshop that Sam_P said...it implied that only a small number were ever repaired, and those were just done to help them figure out what all the problems were. I think that they are now done with that.

2009-03-31 14:16:00 Author: Walter-Kovacs Posts: 542

---

@ walter, still, if I have these problems after the latest update, im pretty sure they want to know why the problem isnt solved. @ ccubbage, my deepest respect for coders, They do the hardest most complicated work, and get the least of attention since most gamers either dont understand the code, or doesnt understand that there is code written at all. So yea, me bashing them and not stating that they did a good job overall was bad from my part, but then again.. its the mistakes you learn the most from, so somebody should point em out, regardless of somebodies feelings. I once had to delete 2 months of work I was very proud of.. It hurts, but learning from my mistakes, my 2nd try was much much better.

2009-03-31 15:03:00 Author: Luos_83 Posts: 2136

---

I wouldn't hold my breath on that. I read something over in LBPworkshop that Sam_P said...it implied that only a small number were ever repaired, and those were just done to help them figure out what all the problems were. I think that they are now done with that. Maybe but it's better to send and take a chance it's repaired then waiting there and making sure your problem will never be solved... .

2009-03-31 17:14:00 Author: RangerZero Posts: 3901

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.