Super Mario Bros. X Forums

zlakerboy357 wrote:I don't know if someone has asked this, but will you able to use LunaDLL with this thing?

No, memory editing is for punks. Open source is the way I'm going.

GhostHawk wrote:memory editing is for punks

Good words, but he meant using LinaDLL's language as script language for levels, but as internal part.

SnifitGuy wrote:I know the NPCs may not be working, but does talking to npcs work?

As you see, and me, and GhostHawk now working on editors.
This is wise: the important to make the structure of game data before making engine part.
Editor is only animator and placing/moving/deleting/changeSettings tool for game's content, and not making game process. "npcs work" - is a realization of his algorithm in game process. It is engine part module.

Wohlstand wrote:

GhostHawk wrote:memory editing is for punks

Good words, but he meant using LinaDLL's language as script language for levels, but as internal part.

Would it need this? Why have a scripting language if the program will be Open Source so everyone can edit it the way they want?

Raster wrote:

Wohlstand wrote:

GhostHawk wrote:memory editing is for punks

Good words, but he meant using LinaDLL's language as script language for levels, but as internal part.

Would it need this? Why have a scripting language if the program will be Open Source so everyone can edit it the way they want?

This is other topic: create the fork of exist project and append this source with other features. Forks also can be used as continue of stopped by official developer project.
LunaDLL at fitst made as mod for SMBX, but his lunadll.txt can be parsed by new engine and used internally. I.e. Use LunaDLL not as memory editor, use them as scripting. For example, I want made in my engine part the NPC-Scripting for any can made his NPC even with modification or creation own algorithm for them. In SMBX impossible replace NPC's algorithm, because it strictly closed to his ID by constant variables in source codes of SMBX.

SnifitGuy wrote:I know the NPCs may not be working, but does talking to npcs work?

No game mechanics are implemented yet, as has been stated many times. The level editor and graphics are being added to the game so it has a framework before the gameplay is coded.

Pseudo-dino wrote:

SnifitGuy wrote:I know the NPCs may not be working, but does talking to npcs work?

No game mechanics are implemented yet, as has been stated many times. The level editor and graphics are being added to the game so it has a framework before the gameplay is coded.

Pretty much this. I want to get all the variables set up before the engine starts using them, and I want to have an optimal system that works well before I get too far into game mechanics where I would need to make major changes. I plan on starting the actual game code around August to September after optimizing performance, efficiency, and fixing bugs. This should also be around the time where I start hiring beta testers, to help with testing editor functionality and what not.

What new stuff will be in the game in terms of npcs, bgos, bgs, and world maps?

PikaChris wrote:What new stuff will be in the game in terms of npcs, bgos, bgs, and world maps?

I think he'll start adding new stuff after he gets the old stuff in.

sleepy wrote:Looks great.
But referring to your Q&A..

Q&A wrote:Why are you even bothering? These projects always fail anyway.

That's because the people who have attempted to recreate it (ex. NSMBX, SMBX:R) don't know shit about coding.

I'd be glad to help you, but VB is not my coding language C and C++ is, sorry.

Goodluck with it, though!

Excuse me, but I know some vb. it's definetly a lot easier than c++ because it's easier than javascript.

lighthouse64 wrote:

sleepy wrote:Looks great.
But referring to your Q&A..

Q&A wrote:Why are you even bothering? These projects always fail anyway.

That's because the people who have attempted to recreate it (ex. NSMBX, SMBX:R) don't know shit about coding.

I'd be glad to help you, but VB is not my coding language C and C++ is, sorry.

Goodluck with it, though!

Excuse me, but I know some vb. it's definetly a lot easier than c++ because it's easier than javascript.

But VB have a big shortcoming:
- slow performance, because all program command calls working through one library, named as VB-RunTime
- lots of bugs in data types converting (for example, as you see bug with decimal separator character, VB can't correctly converting data types, and program will crash with error about wrong data type. C++ compilers will deny working with wrong data types - it will not be compiled. If you got text data from file, data always can be converted into necessary type, even not-numeric string will be converted into integer or into double by char codes).
- closing to Windows Operation System. VB.NET can be build on Linux only with Mono compiler.

Visual Basic - is a amateur tool, for little applications. On VB never written professional and commercial software.
C++ is a professional language, what have a lot of possibles: from console, desktop, server applications, to drivers, firmware, OS kernel, etc. But difficult, because need lot of understanding and knowledge .
Minimal C++ developer kit is a notepad and command line compiler (MinGW or MSVCC on Windows, GCC/G++ on Linux). You always can build C++ application without any IDE, from command line. For C++ any IDE like Visual Studio, Code::Blocks, Qt Creator, Eclipse, Borland C++ Builder is optional, only for speed-up and organize developing process and project files.
For Visual Basic full IDE is important. But VB.NET have possible for build from command line.

Everyone chooses only that langauge that is easier for them.

- closing to Windows Operation System. VB.NET can be build on Linux only with Mono compiler.

Except you can always use WINEHQ, and building on a platform that only 1% of the desktop users use isn't necessary.

Raster wrote:

- closing to Windows Operation System. VB.NET can be build on Linux only with Mono compiler.

Except you can always use WINEHQ, and building on a platform that only 1% of the desktop users use isn't necessary.

.NET Framework doesn't agree with WINE very well.

PS

GhostHawk wrote:This should also be around the time where I start hiring beta testers, to help with testing editor functionality and what not.

I'm up for this.

omg...

GhostHawk wrote:I also plan to add a "Safe-Mode" check box that prevents you from filling your level on accident when using the fill tool. Instead, you will only fill the screen with the block if you mess up.

Thank you, I accidently filled my whole level with blocks and I had to delete em ALL...

Luigifan2010 wrote: PS

GhostHawk wrote:This should also be around the time where I start hiring beta testers, to help with testing editor functionality and what not.

I'm up for this.

I fully intend to ask you later on!

Anyways, I haven't been able to get much work done on VSMBX because I've been working on the forum/IRC full time. I've just implemented an animation priority system to work with my new system for animating NPCs. Also, I've just begun planning out ideas for using INI files to store Object data and Episode save data.

Nothing too big, but I'd figure I would make some update to let you guys know this isn't dead.

Good thing is, I know a fair bit of Visual Basic and I know my way around Visual Studio pretty well so I could always help you in debugging too B)

sleepy wrote:

Q&A wrote:Why are you even bothering? These projects always fail anyway.

That's because the people who have attempted to recreate it (ex. NSMBX, SMBX:R) don't know shit about coding.

It was my understanding that NSMBX was originally intended as a forum for developers for an engine called SMBR, but SMBX: Revived was just a different forum and I don't think anyone, beyond an individual or two, tried to recreate SMBX on there.
There were plenty of people involved on NSMBX and SMBX:R who had nothing to do with attempting to recreate SMBX.

Anyway, GhostHawk, this project looks great. It's amazing that you've kept it going for such a long time.

Could you work on the SMW NPCs next?

Magizard, he may have meant SMB:R. NSMBX was also the name of YoshisIsland's engine.

Sounds stupid but you, wohlstand and luigifan shoud team up to program this :3