Display debug info from script?

So I want to make a mod that implements some arcade style gameplay features and integrates naturally into the existing gameplay, and that also supports some existing mods (but doesn't require them), and I'm an old hat at C#... but to do it... I need to display copious amounts of debug info during gameplay to make sure the code is running properly...

So how do I output debug strings to say the hud or to the chat log or to where ever else I can display them? Outputting to a log file is insufficient for my purposes... I need to see the data as it comes in in real time, it's how I work.

 

MyAPIGateway.Utilities.ShowNotification() for center-hud
MyAPIGateway.Utilities.ShowMessage() for chat

There's also:
MyAPIGateway.Utilities.GetObjectiveLine() for top-left (or center, I forget)
MyVisualScriptLogicProvider.Quest... for top-left quest box like in the campaign.
MyLog.Default.WriteLine() for writing to SE log.

All these except quest are local player, if you want to send them to other players see the notification and chat message stuff in MyVisualScriptLogicProvider, those you can send to player's identityId.

 

Thank you so much... It took some google fu to look up the proper syntax and usage for some of those but I got them working.

Now I'm trying to get debug info about the hit location of weapon shots and raycast hits by painting a GPS signal at the location of the hit.

I'm using this:

IMyGps gps = IMyGpsCollection.Create("Hit Location", "", hitlocation, true, false);
AddGps(MyAPIGateway.Session.Player.IdentityId, gps);

hitlocation is defined as: public Vector3D hitlocation;

I have it displaying the GPS coordinates to the log, and that works... But when I change that to the above lines for using GPS instead, it does not execute... What am I doing wrong?

Also, I am also unable to find any kind of compilation errors in any logs of any sort... Is there a way to view that information?

 

That code isn't valid syntax, the proper way to access that method is MyAPIGateway.Session.GPS.Create(args...)

I strongly suggest using an IDE like visual studio, it'll show you compile issues before you even try to get them in the game.

And the F11 menu in offline mode has the mod errors including compile errors.

 

Ok... thanks. I set up VS2017 Community and have auto completion working on it, and it's giving me the syntax checking I've come to expect, and with that I was able to get GPS marks going and now... I've just never used VS to work with referenced libraries before. It's always been my own projects I've rolled from scratch. (I've reinvented so many wheels over the years).

Another question... I can't find anywhere any information on telling how much time has passed since the last frame... am I going to have to roll my own code on that or does SE provide a conveniently exposed time delta member somewhere?

 

SE always runs at 60ticks per game second, if the hardware can't generate the 60ticks in a real second then that's when simspeed drops, but in-game time is always constant and that's the important part, don't use real time in there

 

All the what? Seriously? That's... I've been making video games for over 10 years... nobody does it that way. you multiply everything by a time delta to keep speeds consistent... the only reason to do it that way is if you care more about simulation accuracy... like... in a scientific sense...

It's no wonder there's so many performance issues, especially with multiplayer...

Seriously, time deltas are not that hard. If they used time deltas, all the sim slow down would basically disappear... sims would run at the same rate regardless of the hardware and only experience issues at severely low framerates... 30, even 15 frames per second on a server should feel playable on the remote player's end, instead of sluggish.

It's not like I'm just blowing smoke here, I've been making multiplayer games for ages. Outside of scientific simulations and recording precomputed physics or rendering high CGI animations like Pixel, or some other thing where you don't have actual gameplay going on, time deltas should be used... It's also so easy that the only excuse for not using them is it being the first game you ever made, coming out of application development, and you not really knowing what you're doing.

I am seriously just all the what? right now

*sigh*

fine... but I don't like it...

 

A dynamic tickrate would introduce different issues I'm sure but that's how they designed it from the start and it's too late to change that now. (I'm not defending their choice tho)

They at least have render separate from game updates, so low FPS doesn't all the sudden cause things to think slower... or faster at >60fps, unlike some AAA games

 

https://gamedev.stackexchange.com/q...f-update-independent-rendering-in-a-game-loop
https://gafferongames.com/post/fix_your_timestep/

Essentially, with all the physics stuff going on in Space Engineers, using dynamic time step would add yet another complication...

 

In my experience the only issues you run into are at super low frame rates with delta time, and there are ways around them... Making a game this complicated aim for 60fps is just asking for performance issues on everything but the latest, greatest, most expensive hardware. Aiming for such hardware is also a great way to justify inefficient coding practices. "Oh it'll be fine, we don't need to optimize this, we're targeting the best hardware on the market, it'll handle it".

In the games I make, I generally aim for physics at no less than 15-20fps with shape casting to detect when collisions are about to occur and then increase the number of discrete steps for objects that are about to collide, and interpolate the movement for everything on the render side. Nobody can really tell the difference and everything is nice and real time.

I can't really say what games I've done, because I'm here to have fun with modding, and it's not a good idea to mix business with pleasure.

Also, Malware, the links you presented talk about why you don't do what Keen is apparently doing, which is to aim for a fixed framerate and do one update per frame and not even keep it sensitive to the amount of time that passes...

And I agree that it's too late for them to change it... this is just one of those moments where I have to pinch the bridge of my nose, groan, accept that I've decided to make mods for an engine that isn't made to my standards, and just get on with it.