Player getting stuck in deep water

[eradicator]

And anyway, as far as i can tell teleporting cars into ungenerated chunks causes no problems whatsoever:

Code: Select all

/c 
  p = game.player
  c = p.surface.create_entity{
    name = 'car',
    position = p.position,
    force = p.force
    }
  c.set_driver(p)
  c.teleport({1e5,1e5}) 

[mrvn]

If by "really fast" you mean driving a car then yes.

Maybe my toaster is simply too fast. But w/e, checking is_chunk_generated() is trival as i already said. What's your point?

My point is that
a) it is a scenario that must be considered. And yes, checking is_chunk_generated() is a possible solution.
b) it isn't just a corner case that never happens in normal games.

You can even trigger it on foot, at least with an exoskeleton or two.

PS: Does is_chunk_generated() return true before the on_chunk_generated() even has finished?

[mrvn]

And anyway, as far as i can tell teleporting cars into ungenerated chunks causes no problems whatsoever:

Code: Select all

/c 
  p = game.player
  c = p.surface.create_entity{
    name = 'car',
    position = p.position,
    force = p.force
    }
  c.set_driver(p)
  c.teleport({1e5,1e5}) 

Unless you land in water and drown? What if the passenger leaves the car in the same tick?

As mentioned I had odd behavior where the player character would become invisible when teleporting into ungenerated chunks.

[eradicator]

Unless you land in water and drown? What if the passenger leaves the car in the same tick?

There is no "drowning". Both cars and charcters can stand on water just fine, even if they can't move.

As mentioned I had odd behavior where the player character would become invisible when teleporting into ungenerated chunks.

Must have missed the part where you said this actually happend and wasn't pure speculation. Have never encoutered it myself either. If you can reproduce "invisible character" you should file a bug.

But to the point: The premise of the @OP is that the player summons an *empty* car to some random position. So none of this applies.

[Pi-C]

2) Characters can't be assigned to players on different surfaces. Which I believes applies to drivers or passengers of vehicles too.

I suppose this wouldn't be relevant either. The way I understand the original mod's code, once a vehicle has been claimed by one player, no other player should be able to use it, so no vehicle claimed by somebody could have passengers.

1) Vehicles can have passengers.

Yes, if you're talking about the vehicle entity -- but a mod can use set_passenger(nil) and set_driver(nil) to eject anybody who enters a vehicle immediately.

But to the point: The premise of the @OP is that the player summons an *empty* car to some random position. So none of this applies.

That was indeed my premise. It's not true anymore, I've spent quite some time on reworking the multiplayer parts of the code (I haven't updated the mod yet, there are still different bits and pieces I've to string together -- and testing for multiplayer by switching between different user sessions with their own instance of Factorio is a massive slow-down), and I've decided that it would be practical if vehicles "owned" by a player could have a passenger. Also, an owned vehicle can't be claimed by somebody else, but if the vehicle isn't locked, it can now be used by others.

So, with the premise changed, I'll also have to look into handling different surfaces, after all. That could take some time, which brings me to another question: When is the right time for releasing an update?

After testing in multiplayer mode, I noticed that the mod doesn't work as promised. I've fixed that now, and added to the logic in my local version, so I could upload a new version now and another version after implementing and testing the teleporting across surfaces.

Pro: Users get a working version as soon as possible.

Contra: Uploading new versions with only minor changes when I know that more changes will be added soon could look like a dirty trick to push download numbers, so I find it more appealing to release a new version that incorporates everything I thought of at the moment.

Which way do you prefer?

[eradicator]

Contra: Uploading new versions with only minor changes when I know that more changes will be added soon could look like a dirty trick to push download numbers, so I find it more appealing to release a new version that incorporates everything I thought of at the moment.

Which way do you prefer?

More users -> more bug reports. Faster release -> earlier bugreports. The numbers are bullshit anyway (sadly), and keeping them "artificially low" does not helping anyone :p. So i release when i got all the features in i want to have and i'm sure enough there aren't any major bugs left.
____________

But...if there's a passenger in someones owned car, do you really want them to be teleported *with* the car? I think i'd prefer to be ejected instead of teleported who-knows-where. But i can see arguments in both directions.

[Pi-C]

More users -> more bug reports. Faster release -> earlier bugreports. The numbers are bullshit anyway (sadly), and keeping them "artificially low" does not helping anyone :p. So i release when i got all the features in i want to have and i'm sure enough there aren't any major bugs left.

Somebody was kind enough to make a translation to Russian. I already asked whether I may contact him again if needed (he agreed). With the current update, I've added some strings and changed some others, and there may be more changes if I try to fiddle with the surfaces. Asking now for a new translation, and asking again next week because there is another update might be taxing his patience, though. That would be another argument for delaying the release.

But...if there's a passenger in someones owned car, do you really want them to be teleported *with* the car? I think i'd prefer to be ejected instead of teleported who-knows-where. But i can see arguments in both directions.

I've already thought of that!

Code: Select all

new_passenger_warn_guest=This locked __1__ belongs to __2__. Only the owner can drive it. __2__ can also summon the __1__ (and you!) anywhere at any time.\nGet out now if that seems too risky!

vehicle_unlock_warn_guest=This unlocked __1__ belongs to __2__. Drive in it, but be aware that __2__ may summon the __1__ anytime and anywhere -- and you with it!

So there are no bad surprises, although the warning may be a bit wordy again. I tried hard to make it shorter, but that's not easy if you need to pack as much information into as few words as possible while phrasing everything gender-neutral -- no matter what I may or may not think about gendering and PC language, but I want to avoid really stupid things like "This car belongs to Susan. Only he may drive it …"

I noticed only during multiplayer testing that driver and passenger can share control of the vehicle (one driving, the other operating the weapons), and as modded vehicles may have more than the 3 weapon slots of vanilla tanks, allowing passengers is a good thing. It could also be that you're stuck somewhere -- teleporting some tiles away could help in that case, but ejecting the passenger before teleporting the vehicle would be really mean!

[eradicator]

You could try publishing the locale file somewhere (i.e. github), then the translator can submit patches he sees fit on his own. You can add comments prefixed with ";" (semicolon, seperate line) too, so if you think something might change in a few days you can just add that info there.

There's also the possibility of using it as a method of teleportation. Just place 20 cars in base before you go to a remote outpost and you can teleport anybody there. *Can* you even own more than one car? Also this reminds me that some (many?) multiplayer games *do* have a "teleport to player x" feature to make coop less annoying. I think i'll add that to my "list of things i'll never mod in the end".

Translation suggestions:
"Dis be Susans turf car. Get out or get teleported!"
"Susans car. Abduction chance while riding: 50%."
"Susan owns this car and can summon it at any time."
"This is Susans car. Don't Panic!"

[Pi-C]

You could try publishing the locale file somewhere (i.e. github), then the translator can submit patches he sees fit on his own. You can add comments prefixed with ";" (semicolon, seperate line) too, so if you think something might change in a few days you can just add that info there.

Github is like dark magic to me (I know, I said something similar about modding once upon a time!), I have no account there, and the only thing I use is "git pull --rebase" to get the latest code of my favorite mail client.

There's also the possibility of using it as a method of teleportation. Just place 20 cars in base before you go to a remote outpost and you can teleport anybody there. *Can* you even own more than one car? Also this reminds me that some (many?) multiplayer games *do* have a "teleport to player x" feature to make coop less annoying. I think i'll add that to my "list of things i'll never mod in the end".

You can own just one vehicle at a time. However, you can lock the vehicle you currently own and give it up by claiming a new one. Locked vehicles can't be mined or moved, and nothing can be taken from them, so in effect, vehicles locked by yourself are still yours. (That's the theory -- just tested, and locked vehicles without an owner can be claimed by anybody with a key, and then unlocked. I'll try to fix this after uploading the current version…)

Translation suggestions:
"Dis be Susans turf car. Get out or get teleported!"
"Susans car. Abduction chance while riding: 50%."
"Susan owns this car and can summon it at any time."
"This is Susans car. Don't Panic!"

The problem goes beyond that, I just found out. English really is a simple language, where articles, adjectives, and pronouns don't change and nouns have just one singular and one plural form (generally, with very few exceptions). In German, articles, adjectives and pronouns are declined along with the nouns. They may have up to four different forms in each singular and plural, and declination depends on the grammatical gender of the noun.

That's an issue even with plain vanilla vehicles: we have "das Auto" (neutral noun for "the car", accusative = nominative) and "den Panzer" (masculine noun for "the tank", accusative, nominative is "der Panzer"). In this case, I could probably select the proper string by checking for type == "car" and name == "tank". However, the mod works with all vehicles of type == "car", and I can't possibly know the names (and the grammatical gender of these words) of every vehicle based on the car prototype that other mods introduce. Even if I knew the names in a given language, I would only be able to assign the correct grammatical gender for that language because it may be different in others (e.g., "la luna" -- Spanish for "the moon" -- is feminine, "el sol" -- Spanish for "the sun" -- is masculine; in German, "der Mond" is masculine, but "die Sonne" is feminine).

I guess there's no easy way to prepare localization files for all these unknown cases, but it causes me real pain to see translations that are plainly wrong (especially if I'm the one who made them so). I'll go into hiding and sulk for a while now …

[eradicator]

And then the non-binary gender people enter the stage and demand you address them "ze" and that that robot over there self-identifies as fourth-gender ;p.

But yea, that's a pretty mean problem. Now that you mention it i'm suprised none of my mods have encoutered it yet. I guess i just don't handle any dynamic mod entities. And there's not really anything you can do about it because the locales have to have the same structure in all languages. So if one language declines the article and the noun, and the next language declines the noun and the verb...then you're pretty much out of luck. I.e. even if you knew the German gender of a "Hovercraft", you don't know the locale of the player, so you'd have to magically find a single print() command that prints correct regardless of the language used.

"Dieses/r __1__ gehört Susanne."

[Pi-C]

And then the non-binary gender people …

You must mean "diverse". You'll find "w/m/d" (or was it "m/w/d"?) in job advertisements here, meaning in English "f(emale)/m(ale)/d(iverse)". I'm not sure, though, how the non-binary gender people feel about that. Sure, they are officially acknowledged now, but being called "diverse" by others? Looks like a new, seemingly polite ostracism to me.

But yea, that's a pretty mean problem. Now that you mention it i'm suprised none of my mods have encoutered it yet. I guess i just don't handle any dynamic mod entities. And there's not really anything you can do about it because the locales have to have the same structure in all languages. So if one language declines the article and the noun, and the next language declines the noun and the verb...then you're pretty much out of luck. I.e. even if you knew the German gender of a "Hovercraft", you don't know the locale of the player, so you'd have to magically find a single print() command that prints correct regardless of the language used.

I've actually thought about that: Make a table with the relevant entity names (either look through all mods yourself or ask you users to report any modded car-entities they care about). Each table entry contains another table, containing language, translation, and grammatical gender of the term in that language. Whenever you want to print the name, lookup the locale used by the player, look up the grammatical gender, and pick the appropriate form. Perhaps localize each term twice (with and without article). Oh, and don't forget that you may need to consider upper/lower case (at the start and in the middle of a sentence). And if you're localizing for German, don't forget that you have up to 24 forms to consider for adjective + noun (4 cases, each for singular and plural; all of that for no article + adjective + noun, indefinite article + adjective + noun, and definite article + adjective + noun. Now you just have to make sure you keep track of all the localization keys and don't mix up arguments in your code. If you're done, you will certainly manage to do some other, trivial things: dividing by zero, building a perpetual motion machine, granting universal peace …

"Dieses/r __1__ gehört Susanne."

Yuck! That looks a bit too formal! I'd even prefer "Dis be Susans turf" over it!

[eradicator]

You must mean "diverse".

No, i meant non-binary. But i have no clue if that is equal to "diverse" or not today. This stuff changes too often and so far i haven't been forced to try to deal with it.

Sure, they are officially acknowledged now, but being called "diverse" by others? Looks like a new, seemingly polite ostracism to me.

No, they demand this by themselfs. According to the internet™, depending on how they feel they will ask you to use a different personal pronoun when addressing "zem". The "z" thing seems to be the "backup" variant in english if you haven't asked the person what their "preferred way to be addressed" is yet:
https://dictionary.cambridge.org/dictionary/english/ze
For german a bit of googling suggests that would be the "x" variants: Xier/Xies etc?:
https://nonbinary.wiki/wiki/Pronouns#Ge ... l_pronouns

lookup the locale used by the player

Before 0.17.69 this was impossible. Now it still requires ugly hacks. Apart from that i think at that point it's better to do the localization completely in lua instead of breaking your fingers trying to bend the locale.cfg system into shapes it was never meant to take :p.

"Dieses/r __1__ gehört Susanne."

Yuck! That looks a bit too formal! I'd even prefer "Dis be Susans turf" over it!

Mission accomplished!

[mrvn]

And then the non-binary gender people enter the stage and demand you address them "ze" and that that robot over there self-identifies as fourth-gender ;p.

But yea, that's a pretty mean problem. Now that you mention it i'm suprised none of my mods have encoutered it yet. I guess i just don't handle any dynamic mod entities. And there's not really anything you can do about it because the locales have to have the same structure in all languages. So if one language declines the article and the noun, and the next language declines the noun and the verb...then you're pretty much out of luck. I.e. even if you knew the German gender of a "Hovercraft", you don't know the locale of the player, so you'd have to magically find a single print() command that prints correct regardless of the language used.

"Dieses/r __1__ gehört Susanne."

It's worse. A Hovercraft is a thing so it would be "Dieses Hovercraft gehört Susanne.". But it's also female as in "She's a beauty". Vehicles are often personified. On the other hand a helicopter is male all the way I would say.

[Pi-C]

"Dieses/r __1__ gehört Susanne."

It's worse. A Hovercraft is a thing so it would be "Dieses Hovercraft gehört Susanne.". But it's also female as in "She's a beauty". Vehicles are often personified. On the other hand a helicopter is male all the way I would say.

No problem, just change the string to
"Diese/r/s __1__ gehört Susanne." (endings in alphabetical order)

It's pretty ugly, but should work. But have I mentioned yet that I think it's ugly? It's that downright-to-the-marrow-of-the-bone kind of ugly, the kind of ugly I don't want to even hear or read about, let alone see for real …

[mrvn]

"Dieses/r __1__ gehört Susanne."

It's worse. A Hovercraft is a thing so it would be "Dieses Hovercraft gehört Susanne.". But it's also female as in "She's a beauty". Vehicles are often personified. On the other hand a helicopter is male all the way I would say.

No problem, just change the string to
"Diese/r/s __1__ gehört Susanne." (endings in alphabetical order)

It's pretty ugly, but should work. But have I mentioned yet that I think it's ugly? It's that downright-to-the-marrow-of-the-bone kind of ugly, the kind of ugly I don't want to even hear or read about, let alone see for real …

The image tag seems to be broken so you have to click at the link yourself:

Lieferschein/innen: http://en.1jux.net/119646-lieferschein-innen

[Pi-C]

Lieferschein/innen: http://en.1jux.net/119646-lieferschein-innen

I'd assume that's an accident, no intent! Perhaps it's a hint that the delivery form is inside, or there may be one on inside and one on the outside. But somebody who really cares about gendering would never spell "innen" with a lowercase "i"!

[Pi-C]

Would it make sense to do the same thing for surfaces? I.e., if the vehicle is on another surface than the player, let the action fail as well? It would prevent all the problems mrvn has pointed out -- but would it be acceptable for players? I've never played on more surfaces than one …

Just get Factorissimo2 and do your own surface experiements. It's probably the most popular surface based mod. Making it generally fail for cross-surface just because there's a 0.1% chance that it might fail seems like a bad solution. As long as there's no passenger/driver in the car it'll always work. And even if there's one it'll still work if the character is attached to a player. So all you need to do is "if not character.player then fail() end" [Edit 1:see below] on both the passenger and the driver. (All "as far as i know", don't forget to do your own testing .)

I just tested with Factorissimo. Looks like I'll have to leave out cross-surface teleporting:

Code: Select all

2010.944 Script @__GCKI__/common.lua:81: Checking surfaces!
2010.944 Script @__GCKI__/common.lua:81: Show entity.name: |car-key| (string)
2010.944 Script @__GCKI__/common.lua:81: Show entity.surface.index: |2| (number)
2010.945 Script @__GCKI__/common.lua:81: Show car.name: |crawler| (string)
2010.945 Script @__GCKI__/common.lua:81: Show car.surface.index: |1| (number)
2010.945 Script @__GCKI__/common.lua:81: Show same_surface: |false| (boolean)
2010.945 Script @__GCKI__/common.lua:81: Trying to teleport crawler from surface nauvis to Factory floor 1
2010.958 Error MainLoop.cpp:1195: Exception at tick 23681: The mod Gizmos Car Keys (improved) caused a non-recoverable error.
Please report this error to the mod author.

And so you can see I just didn't make up a logfile

Error message

error.png (40.88 KiB) Viewed 2328 times

The original mod's code contains nothing that would suggest the author thought of allowing cross-surface summoning of vehicles. But perhaps he had planned it and copied the vehicles instead of teleporting them for just this reason? For now, I'll just bail out with a message if player and vehicle are on different surfaces: that's easy and prevents crashes. After getting some other things off my to-do list, I may consider moving the vehicle by other means.

clone{position=…, surface=…, force=…} may be a way -- I guess it would preserve the current health of the entity? Inventories (trunk, ammo, and fuel) as well as possible grids would have to be copied. But that may (don't know yet, just brainstorming before testing) cause issues with fuel that was in use, or partly emptied stacks of ammo?

[eradicator]

Gosh. I was sure i tested this. But now it seems that i can't even teleport a car to another surface when i'm *inside* the car? Very annoying. Makes me want to implement vehicle support to my teleportation mod even less :(. And i'm sorry for talking buillshit earlier then...

Haven't used clone() yet. I'd assume that it's an exact copy except for the entity unit_number. I'm not sure what it does to the inventory content though. Some items have unique indexes/tags too (blueprints, modded items like factorissimo factories!, etc). So it might be nessecarry to clone the car, but LuaItemStack.transfer_stack() the items.

If you go that far you might as well all pack it up in a generic function that autodecides which method to use ofc...

[mrvn]

Gosh. I was sure i tested this. But now it seems that i can't even teleport a car to another surface when i'm *inside* the car? Very annoying. Makes me want to implement vehicle support to my teleportation mod even less . And i'm sorry for talking buillshit earlier then...

Haven't used clone() yet. I'd assume that it's an exact copy except for the entity unit_number. I'm not sure what it does to the inventory content though. Some items have unique indexes/tags too (blueprints, modded items like factorissimo factories!, etc). So it might be nessecarry to clone the car, but LuaItemStack.transfer_stack() the items.

If you go that far you might as well all pack it up in a generic function that autodecides which method to use ofc...

I'm pretty sure I've driven a car into factorissimo2 buildings. Check their teleport code.

[Pi-C]

I'm pretty sure I've driven a car into factorissimo2 buildings. Check their teleport code.

I tried:

Trying to enter building with car

factorissimo.png (519.88 KiB) Viewed 2244 times

You'll see that both the car and the building are damaged, they just collide. Perhaps I didn't hit the magic point quite right?

Trying to enter building with character

factorissimo_player.png (481.44 KiB) Viewed 2244 times

In this picture, the player is in a position where hitting <W> will teleport him into the building. I'll have a look at the Factorissimo2 code though, maybe I can find something there.