simple machines forum

EDITED: I reuploaded with another fix for object activation.

I recently worked on a problem I thought I fixed a while back but only made worse. The problem is regular object activation for box shaped objects treats them like balls (like items) so that the distance to the box edge isn't significant, and that becomes a problem when even the corners of boxes don't activate them (the original activation distance was much further, but not all boxes are square.)

Fortunately the event trigger system does consider the object's shape, so I ended up rerouting regular activation through that system (some things were already done like this) but while I was doing this I noticed the activation angle I chose was 360 and I thought that didn't make sense for objects.

But what I didn't realize is that angle is actually used to determine where the object is facing and not where the PC (player) is facing. So I've reuploaded the previous patch to fix this (only an hour later.)

Hey if you're still reading this I broke something (http://www.swordofmoonlight.net/bbs2/index.php?topic=316.msg3039#msg3039) when I hastily uploaded those patches the other day. It's about rotating with SOM_MAP. (Edited: Although the view is incorrect in the game, not SOM_MAP.)

The ws.log doesn't show the atipblag.dat file. I wonder why it would be any different. The game uses AvSetMmThreadCharacteristicsA to change its category to "Games" which was one of the crazy secrets you have to learn of to get a game to run at a consistent framerate on Windows. Maybe that makes it to try to find a game profile for it.

Since the behavior was so bad I'm guessing it's an amateur bug in those drivers. Maybe after it didn't crash itself it was able to change its behavior. I wonder why that wasn't on your system. Maybe it's normally in a 64-bit folder? Maybe system32 was the wrong place to be looking for it.

Meanwhile i'll just keep focusing into trying out modelling some stuff and try to pull off what I can, so you most likely will see me asking weird noobish questions.

It's always baffled me that I'm all alone here doing this, it makes me to have a dim view of everyone out there. Please use this sub-board for questions. It's for disposable posts. The main board is for agenda setting, technical topics. If you feel a feature is missing, don't be afraid to ask, but I would still ask on this board, and if something seems feasible in the near term or I have an idea I will put it onto the main board.

I'm excited for new projects. I'd like more varied project spaces to work with. I have hardly any. Don't hesitate to share early results. If you run into a problem (bug/glitch) you'll need to share your files somehow (over link if large) or make a test project that reproduces the problem and link to it.

EDITED: Does the non-debug version NOW work without atipblag.dat?

Okay? So I wonder, does this crummy software that needs that file kill every program when it doesn't get its file? How funny, and poor quality. Normally I'm very displeased with outside software that interferes, but I don't know if it's part of AMD's graphics drivers or not. If not it's part of the company's GPU Control Panel solutions.

Thanks for this screenshot, it looks like I need to disable do_stipple in those language packs! Making a note. It used to look very good on a monitor I had, but it depends a lot on the DPI and generally probably the graphics have come a long way since then, with do_aa. (Note, do_stipple only applies to dithered, 16-bit color modes.)

The text based gauges are part of do_st. My thinking at the time is they look better than the image based ones out of the box. My project has a new mode based on KF, but the compass tends to not be lit well in normal projects, and I haven't figured out how to solve that, but I have a plan. (KF2 uses a complicated color formula that just happens to look good with the compass, the best bet would be to see what happens if you brightened its texture image.)

Your maps can have multiple layers and the clipping is a lot more sophisticated than originally so you can do many things that would glitch crazily otherwise.

I haven't had time to doctor most of the art. I've worked mostly on the map geometry. The other things have lots of holes and seams in their textures. If you want to help patch them over I can facilitate that. If you have better art from your past experience you can copy it into your project's DATA folder and set up additional DATA folders if you need them.

The outdoor set should generally blend the lighting between the titles. Some might be too sharp to, but if you think something isn't blending let me know.

P.S. I'm going to continue to investigate this. I wonder why you were able to get it to work with the Moratheia 2.1 demo for instance. And the other tools for that matter 

BTW: Your last logs.zip file doesn't really help, but it's probably too much to ask to make more since I'd need you to use ws_log_debug_bar=7, and use the new 1.2.3.4d.zip file, AND go back and delete your atipblag.dat file. If you want to do all of that it can help, but if not we can put it behind us, and just assume the atipblag.dat programmers are amateurs. I will add a pop-up box to tell people to make a 0 sized file.

EDITED: I've changed the New Project [Options] to remove do_stipple mainly. You can see them here (http://svn.swordofmoonlight.net/data/my/prof/Ex.ini) but to truly fix them the same file needs to be changed in the text/English/Default.zip data pack. (Note, the linked to file is Japanese, so only change your [Option] section if you want to do that. I would change it in your project at least.) There's a whole lot of these settings, my KF2 project uses a lot more of them. I maintain an unofficial list here (http://en.swordofmoonlight.org/wiki/SomEx/list_of_extensions) that's usually not very up-to-date.

This is part of software development, commercial software firms just have means of doing this before it gets to the customer.

Can you do this with the SOM_PRM model viewer (ws.log) so we can see what a successful log looks like?

This atipblag.dat is part of the driver system or some kind of injected DLL that runs in user space. I'm not sure which. Did you try making a 0 sized file with that name in the system32 folder?

Everything before atipblag.dat looks normal, but after it seems to go downhill. I'd like to think of way to determine if the ATI code is actually killing our program (seems really rude if so) or if som_db.exe is killing itself. But I don't see anything here that would give it a reason to kill itself (like an error that it considers a showstopper.)

The only thing I can think to do is track down where som_db.exe calls FindClose and CloseHandle and mark those and see if I can find code where it exits prematurely. Normally it calls dx_ddraw_DirectDrawCreateEx after and starts using Direct3D.

P.S. That missing file prompt is normal for debug builds. I've added some code to just log it. Please let me see what I can set up to get to the bottom of who's responsible.

EDITED: I think you should've tried my suggestion to set it 8. I have a feeling all of this happens inside dx_ddraw_DirectDrawEnumerateExA and it fails to show any display devices. I see som_db.exe uses OutputDebugStringA so I think I will route it to the log so we can see its output. I may try to add a console feature when I have some free time. 8 should get some useful info in this context.

Strikeout: The new debug build in Reply #17 should output near equivalent info to 8 because som_db outputs that information.

Thanks, this is something to work with. The log is empty. Did you turn on db_log_bardb_log_debug_bar at the bottom of the file? If so, it's something happening nearly as soon as the program begins, probably before the crash dump system is installed. If not  Are you on Windows 10?

Strikeout: The crash system is in place for those messages.

For the record, I tested this, and something I forgot is the log will be called rt.log if you do it with a standalone game like my itch.io demo. A db.log is for the game when using SOM or running a game through it (which also works, i.e. without an EXE.)

I've added LOG to the attachment whitelist, but so short a log you could have quoted it :)

I'll probably need your help to proceed. It looks like maybe there's a problem with shaders, since your log doesn't show that, but it could be something else if you didn't turn on debug logging. (You're not getting to the point where shaders are compiled.)

Routing logs to
C:\Users\Michael\Saved Games\Playing\KING'S FIELD II\rt.log
01/11/21 18:54:32
"C:\Users\Michael\Saved Games\Playing\KING'S FIELD II\KING'S FIELD II.exe"
SomEx.dll 1.2.3.4 attached
Launcher closing log; anticipating next launch date...
NG'S FIELD II\rt.log
01/11/21 18:54:32
"EX\KING'S FIELD II -- som_db.bin" "B:\>" "A:\>"
SomEx.dll 1.2.3.4 attached
Initializing off back of launcher
Exiting DllMain entrypoint
SomEx initialized
Direct3D9 initialized
DirectDraw initialized
PADDING(blit)
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
//   float4 colFactors;
//   float4 rcpViewport;
//
//
// Registers:
//
//   Name         Reg   Size
//   ------------ ----- ----
//   rcpViewport  c1       1
//   colFactors   c2       1
//

    vs_3_0

~~~~~~~~~~~~~~~~~~~~~omitted~~~~~~~~~~~~~~~~~~~~~

    mul r1.xyz, r0, c2.z
    add r0.xyz, -r0, c2.w
    cmp oC0.xyz, r0, c3.x, r1

// approximately 30 instruction slots used (3 texture, 27 arithmetic)
#####
DirectSound initialized
DirectInput initialized
SomEx.dll detached
Have a nice day...

Can you open SOM_PRM (Manage Project) and open the model preview screen, and take a small screenshot of the window (with Alt+PrtSc) and then look for a ws.log file, and see if it has a shader log section.

Then tell me if it has "DirectSound initialized" and "DirectInput initialized" on the following lines. The dump system should be operating. (SomEx-1,2,3,4-SOM_DB_crash_2021-1-06_15-25.dmp is what a file may be named.) Let me see...

Strikeout: Actually, I guess that program doesn't need sound or input (but db.log and rt.log do.)

I've put some log output at the places where a critical error causes termination (should've done this already) and uploaded a debug build in case we need it:

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4d.zip

Don't worry about the debug build. It will be more useful for a crash dump, but since you're not getting a dump, it may not be crashing. If you do swap in the debug build, you must remember to swap back the normal build when finished. Although it's probably harmless. Anyway, please try again with this DLL. And know that the DLL goes in the TOOL folder for SOM and in the EX/SYSTEM folder for standalone EXE games.

P.S. You're probably not the only one in this boat, so please stick with it

1) SOM_RUN isn't what you think. Just leave that alone.

2) If Moratheia worked, are you using GAME.EXE because if so, that's using 2000 SOM like we discussed. If not, you should copy your latest SomEx.dll file into its EX/SYSTEM folder to get the best experience, since it's is quite old.

I can only say, do what I said about do_log/db_log_bardb_log_debug_bar and see if it makes a db.log file. I can't think of a reason you wouldn't have DMP files if it is crashing, assuming you're in the right folder.

You seem to have an issue just with the game playing component. Its log is db.log. And you should turn off do_log/db_log_bardb_log_debug_bar when you're done because the debug log on it will generate huge log files.

It doesn't do anything special that the tools don't do, so I'm drawing a blank. I would think it's your project, but since you say my project (KFII) isn't working either, it's very perplexing.

So, please keep trying to see what you can find out. Also tell me if Moratheia.exe works for you. And then tell me if it works with the current SomEx.dll. Thanks for helping.

BTW: The Moratheia project is really cool (it's a full length game) but it's not balanced for SomEx and it wasn't made for the do_aa extension, so if you don't like the cracks that appear because of that you should turn it off and use your GPU Control Panel's AA options. And I don't know what it's like with the GAME.EXE balance wise, but without you just have to kind of accept that it's basically a demo. The F3 function will keep you alive. The equipment stats don't matter very much since I faked some damage formulas to make it basically playable. It feels pretty good, especially the last dungeon, but I wish its monsters had more limited hit range on their attacks. Then it would feel like a really good/fair game with SomEx.