Excellent tool. Oddly, I ran it once on my server map and it seemed to work correctly. Then I reset my server files, and upon running it again, it say "Processing" for a short while then crashes out.
I seem to still be able to run my server, the server software runs. Of course, I can't log into it right now cause minecraft.net is down. Any ideas why it might be crashing out though?
Here is the error log
Problem signature:
Problem Event Name: APPCRASH
Application Name: oregen.exe
Application Version: 0.0.0.0
Application Timestamp: 4d35082f
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.7600.16385
Fault Module Timestamp: 4a5bda6f
Exception Code: c0000005
Exception Offset: 00009c7f
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 4105
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
It could be an out of bounds read or write somewhere. Is it repeatable? (That is, assuming you made a backup of your world first, can you try running it again on a copy)
If you're up to it, you could install DrMingw (http://code.google.com/p/jrfonseca/wiki/DrMingw) as a debugger, and the next time the tool crashes, DrMingw would pop up with a complete backtrace at the time of crash. That would be very helpful to me, but don't feel pressured if you're not comfortable dealing with that stuff or you already have development tools set up that you don't want messed with.
Great, thanks for this. It's crashing in cnbt on read. It looks like malloc is failing. Interesting.
If you don't mind, I'd like to take further debugging to PM. It might require some back-and-forth to exactly pinpoint the problem. I'll send a new build in a little bit with some extra assertions to see if this is accurate.
Default mode without -oo or -ob will only overwrite rock with new ores? Or rock, cobblestone, gravel, and dirt? I'm about to run this on a heavily built SMP map and wanted to make sure I understand what it considers valid areas to place new deposits.
Thanks for the awesome tool - aside from updating for the Lapis, this will help us continue to use the same MP map without worrying about resource depletion.
The crashing reported by Pelvidar was a result of malformed chunks in the save, and the crash was originating in the NBT library as a result.
I have updated OreGen again to detect and report more severe instances of malformed chunks (which will also be skipped over, so that the utility doesn't crash). I would advise trying to verify these reports in another tool like MCEdit, and delete those chunks.
I ran across viewtopic.php?f=1022&t=127216 earlier today. I haven't tried it myself, but it looks very useful and if you have corruption bad enough that OreGen is reporting it, I would recommend running a more comprehensive checker like this one. You may have more subtle chunk corruption that OreGen is able to detect.
I made the changes that I noticed. Try building it. The makefile now takes either "make windows" or "make linux", mostly to sort out the zlib business.
No, the only difference is the compiler options (mainly that I statically link to zlib for windows/mingw, but pretty much all Linux users already have zlib as a shared library).
i have almost no clue of c, but won’t it work to use the ifdefs as preprocessor statement?
this way it will work automagically and the makefile will need no targets and be simpler.
Topics about absence of lapis in pre 1.2 maps starts to emerge, and people are linking to your topic. For me command line software is no problem at all. I work on linux servers a lot so it's intuitive for me, but for many people it's hard to use it. Maybe you could write some kind of wrapper with GUI to your application. This way you can keep this tool the way it is and still let people without that knowledge to use it. McMap is created similar way and it works like a charm :smile.gif:
hmm, you mean just a gui where you have all options as widgets?
i could do this in qt4. it would only call the cli-program with the proper arguments however, since it would be my first c++-project and i’d like to keep things simple.
if i do it, i will publish the source, of course, so someone can wrap it up proplerly.
essentials:
fileseletor: <world dir>
dropdown box: <ore_id>
optional (=preset) stuff:
spinbox: Number of rounds ore is generated per chunk
combined range slider: Minimum and maximum depth ore is generated (0-127)
range slider: Size of ore deposit (0-63) -- Defaults: Coal = 16, Iron/Gold = 8, Redstone/Diamond/Lapis = 7
disableable time spinbox: Only update chunks modified before time (as unix timestamp)
disableable time spinbox: Only update chunks modified after time (as unix timestamp)
checkbox: Take precedence over all existing ores
checkbox depending on the above one: Take precedence over all existing blocks (including air)
You could create a header file that contains relevant structs and function signatures. Or you could extern them. In theory there's only one function you'll ever directly invoke since everything is controlled by an options struct you pass through.
you sir, just won the game!
http://tinyurl.com/9l6km29
I seem to still be able to run my server, the server software runs. Of course, I can't log into it right now cause minecraft.net is down. Any ideas why it might be crashing out though?
Here is the error log
Problem signature:
Problem Event Name: APPCRASH
Application Name: oregen.exe
Application Version: 0.0.0.0
Application Timestamp: 4d35082f
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.7600.16385
Fault Module Timestamp: 4a5bda6f
Exception Code: c0000005
Exception Offset: 00009c7f
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 4105
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
If you're up to it, you could install DrMingw (http://code.google.com/p/jrfonseca/wiki/DrMingw) as a debugger, and the next time the tool crashes, DrMingw would pop up with a complete backtrace at the time of crash. That would be very helpful to me, but don't feel pressured if you're not comfortable dealing with that stuff or you already have development tools set up that you don't want messed with.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Well, I'm no expert at this, but I thik this is what you were looking for:
oregen.exe caused an Access Violation at location 76479c7f in module msvcrt.dll Writing to location 00000000.
Registers:
eax=00000000 ebx=00465884 ecx=01ffffae edx=0000007f esi=00000000 edi=00000000
eip=76479c7f esp=0028fc34 ebp=0028fc38 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
76479C7F msvcrt.dll:76479C7F _ftol2
76479C39 msvcrt.dll:76479C39 _ftol2
004037E5 oregen.exe:004037E5 nbt_read_string nbt.c:265
int nbt_read_string(
nbt_file * nbt = &{
gzFile fp = 0x00343828,
nbt_tag * root = 0x00465880
},
char * * out = &0x00000000
)
004032B9 oregen.exe:004032B9 nbt_read_tag nbt.c:63
int nbt_read_tag(
nbt_file * nbt = &{
gzFile fp = 0x00343828,
nbt_tag * root = 0x00465880
},
nbt_tag * * parent = &0x00465880
)
00403222 oregen.exe:00403222 nbt_parse nbt.c:41
int nbt_parse(
nbt_file * nbt = &{
gzFile fp = 0x00343828,
nbt_tag * root = 0x00465880
},
const char * filename = &'D'
)
00401FC7 oregen.exe:00401FC7 update_chunk oregen.c:345
int update_chunk(
char * file = "D:\@Home\Games\Minecraft\Server0\prime/h/1f/c.h.1f.dat",
int ore_id = 21,
struct options * opt = &{
long unsigned int set = 0,
long unsigned int c_time = 2622013031,
long unsigned int m_time = 4294967294,
int rounds = 1,
int min_depth = 0,
int max_depth = 32,
int size = 7,
int x1 = 4261398,
int y1 = 4261296,
int x2 = 7288152,
int y2 = 56,
int data = 2130567168
}
)
0040269F oregen.exe:0040269F update_all_chunks oregen.c:507
int update_all_chunks(
char * path = "D:\@Home\Games\Minecraft\Server0\prime",
int ore_id = 21,
struct options * opt = &{
long unsigned int set = 0,
long unsigned int c_time = 2622013031,
long unsigned int m_time = 4294967294,
int rounds = 1,
int min_depth = 0,
int max_depth = 32,
int size = 7,
int x1 = 4261398,
int y1 = 4261296,
int x2 = 7288152,
int y2 = 56,
int data = 2130567168
}
)
0040316E oregen.exe:0040316E main oregen.c:717
int main(
int argc = 3,
char * * argv = &0x00340f11
)
004010B6 oregen.exe:004010B6
00401148 oregen.exe:00401148
760D3677 kernel32.dll:760D3677 BaseThreadInitThunk
77C59D42 ntdll.dll:77C59D42 RtlInitializeExceptionChain
77C59D15 ntdll.dll:77C59D15 RtlInitializeExceptionChain
If you don't mind, I'd like to take further debugging to PM. It might require some back-and-forth to exactly pinpoint the problem. I'll send a new build in a little bit with some extra assertions to see if this is accurate.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Default mode without -oo or -ob will only overwrite rock with new ores? Or rock, cobblestone, gravel, and dirt? I'm about to run this on a heavily built SMP map and wanted to make sure I understand what it considers valid areas to place new deposits.
Thanks for the awesome tool - aside from updating for the Lapis, this will help us continue to use the same MP map without worrying about resource depletion.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I have updated OreGen again to detect and report more severe instances of malformed chunks (which will also be skipped over, so that the utility doesn't crash). I would advise trying to verify these reports in another tool like MCEdit, and delete those chunks.
I ran across viewtopic.php?f=1022&t=127216 earlier today. I haven't tried it myself, but it looks very useful and if you have corruption bad enough that OreGen is reporting it, I would recommend running a more comprehensive checker like this one. You may have more subtle chunk corruption that OreGen is able to detect.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
did you try using #ifdef WIN32 or #ifdef UNIX or something?
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
this way it will work automagically and the makefile will need no targets and be simpler.
Does anybody know what im doing wrong ?
hmm, you mean just a gui where you have all options as widgets?
i could do this in qt4. it would only call the cli-program with the proper arguments however, since it would be my first c++-project and i’d like to keep things simple.
if i do it, i will publish the source, of course, so someone can wrap it up proplerly.
This sounds awesome. It'd be cool to spawn glowstone so you could mine it to use as an alternate light source in SMP since we don't have nether.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
[*:3319nn9q]the structs and[*:3319nn9q]update_all_chunks
correct?