![Smile :)](./images/smilies/icon_smile.gif)
I don't have any feedback on the project, but I didn't want this thread to pass by with only cricket noises.
It's an impressive thing to have done
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Moderator: Graphics Moderators
Thanks. I really appreciate that.I don't have any feedback on the project, but I didn't want this thread to pass by with only cricket noises.
Maybe. The particular error code I get seems related to heap corruption. This is not generally a feature of my code, but no one is perfect. I have used shared_ptr and STL containers throughout, and perform no direct resource management. I'll see if I can track it down this evening.undefined behaviour
Right first time: twice incrementing a counter between sequence points in the chunked tile decoder. At least it wasn't too hard to find.jfs wrote:undefined behaviour
Thanks very much.
I have been a bit distracted but have started a little documentation. It's mostly a pretty thin thing at the moment, barely a beginning with some structure but lots of empty pages, but I would be very grateful for feedback. These pages and a few others are worth a look:
Code: Select all
yagl.exe -d dutchtrains.grf
Code: Select all
// Record #988
strings<Trains, default, 0x013A> // <feature, language, first_id> Action04, Default
{
/* 0x013A */ "{black}NS 5500 (Steam {green}locomotive {red}(added in YAGL){black})";
}
// Record #989
strings<Trains, de_DE, 0x013A> // <feature, language, first_id> Action04, German
{
/* 0x013A */ "NS 5500 (Dampf)";
}
Code: Select all
yagl.exe -e dutchtrains.grf
Bugger! These are Visual Studio re-distributable files. I was pretty sure that using a static build would eliminate this sort of thing.
Sure. But I hope you'll give it a spin. My original goal was to look inside the GRFs generated with NML. I thought it would be interesting to see how the NML constructs are mapped onto the underlying NewGRF specs used for NFO. I wondered if it might help with debugging or something.andythenorth wrote: ↑05 Apr 2020 19:33 It's not something I can use, I've too much work tied up with nml, but it's nice to see a new toolchain develop.
I'm using it to help demystify uncommented NFO source code, especially when the only thing that exists is the compiled GRF. There's a lot of NewGRFs whose authors, experience and documentation have disappeared, leaving behind only the finished product.UnicycleBloke wrote: ↑06 Apr 2020 13:47 Sure. But I hope you'll give it a spin. My original goal was to look inside the GRFs generated with NML. I thought it would be interesting to see how the NML constructs are mapped onto the underlying NewGRF specs used for NFO. I wondered if it might help with debugging or something.
You just made my day! Let me know if there is anything I can help with or add to the software to make life easier.
You might need to consult MacBeth's three witches who noted toil and trouble.
Code: Select all
08 Global Settings - Cost base multipliers (08)
00 Trains - Cost factor (17)
01 Road Vehicles - Cost factor (11)
02 Ships - Cost factor (0A)
03 Aircraft - Cost factor (0B)
Code: Select all
properties<GlobalSettings, 0x0000> // Action00
{
// instance_id: 0x0000
{
cost_base_multipliers: 0xFF;
}
}
Code: Select all
properties<Ships, 0x0000> // Action00
{
// instance_id: 0x0000
{
introduction_date: 0x0000;
reliability_decay_speed: 32;
vehicle_life_years: 30;
model_life_years: 40;
climate_availability: Temperate | Arctic | Tropical | Toyland;
sprite_id: 0xFF;
is_refittable: true;
cost_factor: 0xFF;
speed_2_kmh: 0xFF;
cargo_type: 0xFF;
cargo_capacity: 0x0F28;
sound_effect_type: 0x07;
refit_cargo_types: 0x00000000;
callback_flags_mask: 0x00;
refit_cost: 0x32;
ocean_speed_fraction: 0x00;
canal_speed_fraction: 0x5B;
miscellaneous_flags: 0x02;
refittable_cargo_classes: 0x01D1;
non_refittable_cargo_classes: 0x0000;
}
}
Users browsing this forum: No registered users and 2 guests